COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	1. What else will be in this report - the unit's package?
C00003 00003	RLL 
C00014 00004	@InProceedings(RLL,
C00016 ENDMK
C⊗;
1. What else will be in this report - the unit's package?
2. What formatting system? SCRIBE?
3. Purpose of this report - to convince others of RLL's utility,
	or demonstrate its abilities, or ...
	In 1/2 page...
  Feel free to subset this to the size you wish.
RLL 

Motivation

	RLL is a tool to facilitiate the building of expert  programs
quickly.  It is itself an  expert program, whose domain of  expertise
is knowledge representation.

Task Description

	The standard  first step  taken  in building  an  application
program in AI  is the design  and implementation of  a language  
in which to
represents the knowledge the program will use.  Experience has  shown
that the language  developed in one  application is seldom  adaptated
for use in  other programs -- the  features that were  useful for  the
original problem become limitations  elsewhere.  Thus, a  specialized
representation language  is  redesigned and  reimplemented  for  each
application -- a very time consuming task.

	RLL (Representation Language Language) is designed to  reduce
the time  spent  building such  representation  languages.  It  is  a
language  which  "knows"  about  the  components  of   representation
languages in  general.   It  provides the  user  with  an  extendable
collection of high level operators and constructs which he can use to
describe and build components of his target language.  After the user
has specified  the desirable  features of  the target  language,  RLL
integrates these  components into  a functional,  new  representation
language.  In other words,  a user can readily  and rapidly design  a
personalized  language,  exactly  suited   to  the  domain  and   the
application task at hand.

	RLL is an open-ended language in which the user can add pieces
of language not provided in  RLL's standard repetoir.  Currently  RLL
can deal  with  pieces  such  as slots,  modes  of  inheritance,  and
specification of functions.  Slots conform to the definition given in
the UNITS package  (see page ?).   In fact, RLL  borrowed much of  its
nomenclature, as well as software, from UNITS.  For example, it  uses
one of  UNITS  main  mode  of inheritance,  the  Example link.   This
inheritance  relationship  corresponds  to   set  theory  notion   of
"element-of".  However, there is  nothing in UNITS which  corresponds
to RLL's use of functional  specification.  This domain is  currently
being explored, because  it would help  unify many outwardly  diverse
concepts, such as processes, mechanisms, and slots.

	The  initial   RLL  system   is  itself   a  very   versatile
representation language.  For most tasks, the  user can use it as  he
might any other representation  language.  What distinguishes RLL  is
that the user is not forced to follow the constraints imposed by a
particular language;  instead,  he  can  mold  his  copy  of  RLL  to
accomodate his particular task.

	RLL  derives  this  flexibility  in  two  ways.   First,  RLL
contains a  large  library  of  largely  independent,  pre-fabricated
"representational pieces".   For example,  there are  many  (mutually
incompatible) ways in which one  can associate facts with an  object.
One corresponds to UNIT's idea of a slot, while another is the use of
pointer to a list or relevant assertions.  For example, consider  how
to represent "Fred  is the  Father of Mary".   Using slots,  "Father"
slot of the unit Mary would  be filled with the value "Fred".   Using
links, the  unit Mary  would  point to  the assertion  "(Father  Mary
Fred)".  The first method, using  explicit slots, is "active" in  the
initial RLL system.  If this  proves unsatifactory, a simple  command
will instruct RLL  to switch to  the second method.   From then  on,
(or, at least,  until the  user's next alterring  command) the  user
modified  version  of  RLL  will  prevail.   Furthermore,  RLL   will
automatically convert the user's existing data into the new format.

	To effectively  use  the  variety  of  components,  RLL  must
"understand" what each does, and how.  This information allows RLL to
mesh diverse parts together  to form a  coherent and workable  whole.
As such,  it should  be possible  for  the user  to design  a  fairly
arbitrary language by simply choosing the precise amalgamation of the
pieces he needs, leaving  to RLL the  responsibility of fitting  them
together.

	Cataloging of  possible  components  will  never  be  totally
complete.  RLL's second approach towards generality is its  collection
of tools designed  to help the  user fabricate new  parts.  A set  of
high-level operators are  provided so  that the user  can define  new
components or a type of components, or refine existing ones.

	For example, the user  can define the  "Parents" slot as  the
union of the "Mother" and "Father" slots.  That is, the value of  the
"Parents" slot of an individual is a list consisting of the values of
that person's "Mother"  and "Father" slots.   This brief  definition,
Parent = Union(Mother Father), is sufficient to tell RLL everything it
needs to  know  about this  slot.   RLL now  knows  to  automatically
invalidate  the  value  stored  for  Fred's  parents  if  his  mother
remarries.  Furthermore  it knows  that only  some units  may have  a
Parents slots, i.e. those which have both a Mother and Father slots.
(Hence while each person or zebra should have parents, we should not
expect a VLSI chip to have such a slot, nor the unit representing the
class of functions.)

	The language  parts, however  they were  derived, become  the
language the  user can  use  for his  task.   If he  later  discovers
limitations in  this  set  he  need only  replace  or  redesign  the
offending components.  RLL's  collection of types  of parts, and  its
high-level operators, make modifications relatively simple.  As shown
above, RLL  then  does  the  "busywork",  such  as  reformatting  the
existing data to conform to the set of new conventions.

Current Status

	Although interests have  been expressed  in using  RLL for  a
variety  of  applications,  the  system  has  only  recently   become
sufficiently stable to  permit others to  use it.  
RLL's power can be seen in the variety of tasks in which it has been employed:
an adventure game  simulation
an (internal) exploration towards a more complete self-description  of  its
various parts using lower-level primitives,
and a complex task in which RLL assumed the role
of expert-system builder,  designing a program to
handle with oil spills (see Hayes-Roth et al.).
@InProceedings(RLL,
Key = "Greiner",
Author = "Greiner, Russell and Lenat, Douglas B.", 
Title = "A Representation Language Language",
Booktitle = "1-AAAI",
Organization = SU,
Month = AUG, Year = 1980)

@TechReport(RLLa,
Key = "Greiner",
Author = "Greiner, Russell", 
Title = "RLL-1: A Representation Language Language",
Number = "HPP-80-9",
Type = WP, 
Institution = CSDSU,
Month = OCT, Year = 1980)

@TechReport(RLLb,
Key = "Greiner",
Author = "Greiner, Russell and Lenat, Douglas B.", Title = "Details of RLL-1",
Number = "HPP-80-23",
Type = WP, 
Institution = CSDSU,
Month = OCT, Year = 1980)

@Manual(MRS,
Key = "Genesereth",
Author = "Genesereth, Micheal, Greiner, Russell, and Smith, David", 
Title = "MRS Manual",
Note = "HPP Working Paper HPP-80-24", Month = DEC, Year = 1980)

@UnPublished(ExpertSystems,
Key = "Hayes-Roth",
Author = "Hayes-Roth, Frederick, Waterman, D. A. and Lenat, Douglas B.",
Title = "Designing Expert Systems", Note = "in construction")

@Manual(Units,
Key = "Smith",
Author = "Smith, Reid G. and Friedland, Peter",
Title = "Unit Package User's Guide",
Month = DEC, Year = 1980,
Note = "(HPP-80-28, and Defence Research Establishment Atlantic # 80/L)")